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Claims 1-14 stand rejected under 35 U.S.C. § 101 on grounds that the claimed invention 

. I 

is directed to nonstatutory subject matter. As will be shown befow claims 1-7, as 
currently amended, include physical structure for implementing the method recited in 
claims 1-7 and claims 8-14, as originally submitted, include physical structure for 
implementing the system recited in claims 8-14. Applicants therefore respectfully 
request reconsideration of claims 1-14. J 

I 

Claims 5-7, 12-14, and 19-21 stand rejected under 35 U.S.C. §112, second paragraph, for 
failing to particularly point out and distinctly claim the subject matter which Applicants 
regard as the invention. As will be shown below the "second domain metric vector/ 
vector action list / user metric space..." of claims 5-7, 12-14, dnd 19-21 need no extra 
antecedent basis. Applicants therefore respectfully request reconsideration of claims 15- 
7, 12-14, and 19-21. I 

l 

Claims 1-21 stand rejected under 35 U.S.C. § 102(e) as being knticipated by Trossen, et 
al (U.S. Publication No. 2003/0204599) (hereafter Trossen') t As will be shown below, 

Trossen, does not anticipate administering devices as claimed In the present application. 

I 

Claims 1-21 are therefore patentable and should be allowed. Applicants respectfully 

traverse each rejection individually below and request reconsideration of claims 1-21. 

I 

I 

Claim Rejections - 35 U.S.C. § ldl 

I 

Claims 1-14 stand rejected under 35 U.S.C. § 101 on grounds that the claimed invention 
is directed to nonstatutory subject matter. The Office Action advises that claims 1-14 
constitute software per se as no physical structure is present fj>r implementing either the 

method or system. Applicants have accordingly amended thel method of claim 1 to recite: 

I 

I 

1 . A method for administering devices , the method implemented with 

two data processing domains, a first domain aiid a second domain, 

I 
I 
I 
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each domain comprising a networked data processing environment. 



the domains coupled for data communications , the method 



comprising: 



receiving , in the second domain from the first domain, a domain 

state object , the domain state object comprising information 

i 

representing a state of the first domain ; I 



identifying by the second domain an action in d< 
domain state object; and i 




upon the 



the second domain's executing the action. 



It is thus apparent that the method of claim 1 as currently amended is implemented by a 

i 

physical structure, two data processing domains coupled for data communications, each 

i 

domain comprising a networked data processing environment.| Dependent claims 2-7 
depend from claim 1 and include all limitations of claim 1 incjuding the physical 
structure used to implement the method of claim 1 . The method of claim 1 is patentable 
under 35 U.S.C. § 101 because it implemented with a physical structure. Claims 2-7 are 
also therefore patentable under 35 U.S.C. § 101 for the same reason. The original 
specification in this case is replete with enabling descriptions pf data processing domains, 
Applicants therefore respectfully submit that the current amendment adds no new matter 
to the present application. Applicants respectfully request rec'onsideration of claims 1-7. 



Claims 8-14 are directed to a system for administering devices according to embodiments 
of Applicants' present application. During patent examinatioh, the pending claims must 

be given their broadest reasonable construction M in light of the specification as it would 

i 

be interpreted by one of ordinary skill in the art." Phillips v. 4WHCorp., 415 F.3d 1303, 
1316 (Fed. Cir. 2005), citing In re Am. Acad of Set Tech Ct\., 367 F.3d 1359, 1364 
(Fed. Cir. 2004). Applicants' original specification at page 7 f lines 7-10, describes a 
"system" as "any computer system that includes suitable programming means for 
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operating in accordance with the disclosed methods. . ." A computer system that includes 
suitable programming means for operating in accordance with Applicants' disclosed 
methods is a physical structure. The system of claims 8-14, wfyen read in light of the 
specification, is therefore drawn to a computer system, a physical structure for 
implementing claims 8-14. Because claims 8-14 include a physical structure claims 8-14 
are patentable under 35 U.S.C. § 101. Applicants respectfully jequest reconsideration of 
claims 8-14. | 

i 

Claim Rejections - 35 U.S.C. § 112, Second paragraph 

i 

Claims 5-7, 12-14, and 19-21 stand rejected under 35 U.S.C. §[112, second paragraph, for 
failing to particularly point out and distinctly claim the subjectl matter which Applicants 
regard as the invention. The Office Action advises that the "sejcond domain metric 
vector/ vector action list / user metric space..." of claims 5-7, 12-14, and 19-21 lacks 
antecedent basis. As explained below in more detail, the "seccjnd domain metric vector/ 
vector action list / user metric space..." of claims 5-7, 12-14, dnd 19-21 has sufficient 
antecedent basis. The rejections under 35 U.S.C. § 112, Seconal paragraph, should 

therefore be withdrawn and claims 5-7, 12-14, and 19-21 shoiild be allowed. 

I 

I 

"A second domain metric vector" as recited in claims 5, 12, arid 19 has sufficient 

I 

antecedent basis to satisfy the requirements of 35 U.S.C. § 11^, second paragraph. "A 

second domain metric vector" is a metric vector for a second domain, referred to for 

I 

clarity as a second domain metric vector. A second domain metric vector is not another 
domain metric vector. Because the metric vector of claims 5, '12, and 19 is only referred 
to for clarity as a second domain metric vector and is not another domain metric vector, 
"a second domain metric vector" therefore in fact has sufficient antecedent basis, and the 
rejections under 35 U.S.C. § 112, second paragraph, should b? withdrawn. Applicants 
respectfully request reconsideration of claims 5,12, and 1 9. J 

I 

"A second domain vector action list" as recited in claims 6, 1^, and 20 has sufficient 

I 

antecedent basis to satisfy the requirements of 35 U.S.C. § 1 12, second paragraph. "A 
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l 

second domain vector action list" is a vector action list for a second domain, referred to 

i 

for clarity as a second domain vector action list. A second domain vector action list is not 
another vector action list. Because the vector action list of claijns 6, 13, and 20 is only 

referred to for clarity as a second domain vector action list and is not another domain 

i 

vector action list, "a second domain vector action list" therefor^ in fact has sufficient 
antecedent basis, and the rejections under 35 U.S.C. § 112, second paragraph, should be 

withdrawn. Applicants respectfully request reconsideration of claims 6, 13, and 20. 

I 
I 

"A second domain user metric space" as recited in claims 7, l4 and 21 has sufficient 
antecedent basis to satisfy the requirements of 35 U.S.C. § \\2[ second paragraph. "A 
second domain user metric space" is a user metric space for a second domain, referred to 

for clarity as a second domain user metric space. A second doihain user metric space is 

i 

not another user metric space. Because the user metric space qf claims 7, 14, and 21 is 
only referred to for clarity as a second domain user metric spacie and is not another 
domain user metric space, "a second domain user metric spacel" therefore in fact has 
sufficient antecedent basis and the rejections under 35 U.S.C. jjj 1 12, second paragraph, 

should be withdrawn. Applicants respectfully request reconsideration of claims 7, 14, 

I 

and 21. | 

l 

Claim Rejections -35 U.S.C. § 102 Over Trossen 

I 

l 

Claims 1-21 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Trossen, et 
al (U.S. Publication No. 2003/0204599) (hereafter 'Trossen') 1 . "A claim is anticipated 
only if each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference." Verdegac^l Bros, v. Union Oil Co. of 

California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Dir. 1987). As explained in 

I 

more detail below, Trossen does not disclose each and every element of claim 1, and 
Trossen therefore cannot be said to anticipate the claims of the present application within 
the meaning of 35 U.S.C. § 102(e). ! 

Independent claim 1, as currently amended, claims: , 
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! 

1 . (Currently Amended) A method for administering devices , the 

method implemented with two data processing domains, a first 

_ i 

domain and a second domain, each domain comprising a 
networked data processing environment, the dorjiains coupled for 

data communications , the method comprising: [ 

I 

! 

receiving , in the second domain from the first domain, a domain 

i 

state object , the domain state object comprising information 

representing a state of the first domain ; J 

i 
i 

identifying by the second domain an action in dependence upon the 

domain state object; and J 

i 
i 

the second domain's executing the action. 1 

i 
i 

Trossen Does Not Disclose Receiving A Domain State 
Object, Identifying An Action In Dependence Upon The 
Domain State Object, Or Executing Th^ Action 

The Office Action takes the position that Trossen at paragraphs 0024-0027, discloses 
every element of claim 1 as claimed prior to the current amendment: receiving a domain 
state object, identifying an action in dependence upon the doihain state object, and 

executing the action. Applicants assume in the following remiarks that the Examiner 

i 

would also take the position that Trossen anticipates claim 1 as currently amended. 
Applicants respectfully note in response, however, that what 'jrossen at paragraph 0024- 
0027, in fact discloses is: 1 



[0024] Suppose now that the user desires to move 12 from the current 
WLAN administrative domain 15 to a new administrative domain 19 in 
communication with new access router 18 and new access network 20. 
Suppose also that the bandwidth in new administrative domain 19 is less 
than the WLAN administrative domain. This would 'typically be the case 
for example if the new administrative domain happens to be the outdoor 
cellular coverage. Because the session was established with higher 
bandwidth capabilities, the session may be unable to continue 
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uninterrupted in its current state as regards resolution speed of video 
motion, size of displayed pictures, color combinations, clarity of audio etc. 
Some of these parameters need to be changed so that thb video stream can 
fit in the new bandwidth constraints. To achieve this, prior to handoff from 
access router 14 to access router 18, MT 12 constructs an application 
context for the video session and registers 72 it with ciirrent access router 
14. It may create the application context, for examplei, from information 
obtained in the SDP descriptive information in the SIP INVITE message 
from CS 22 and from MT 12's subsequent response. In irder to register the 
application context, MT 12 formats the application qontext information 
into a pre-determined format that such access routers n^ay accept. The pre- 
determined format may be according to a standard, such as one 
recommended by IETF. As an example, the standard format could be an 
object that could be used by an object-oriented application running on 
access routers 14, 18. Such object technologies, for expnple, may include 
Common Object Request Broker Architecture (CQRBA), Distributed 
Component Object Model (DCOM), Simple Object Access Protocol 
(SOAP), Enterprise Java Beans (EJB), and Type Length Value (TLV). 



[0025] After MT 12 creates and formats the application context for the 
video session, it registers 72 the context by transferring it to current access 
router 14, for example, via IP messaging. Such IP messaging may make 
use of protocols, for example, like Internet Control Message Protocol 
(ICMP), User Datagram Protocol (UDP), Transmission Control Protocol 
(TCP), and Stream Control Transmission Protocol (sbTP). According to 
one aspect of the invention, the transfer of application context to current 
access router 14 occurs along with a handoff trigger rriessage from MT 12, 
such as an indication of a reduction in signal strength,. According to other 
aspects, the application context may be transferred at ithe beginning of the 
session, at handoff, or almost any other time therebetween. As shown in 
FIG. 6, registration 72 may occur at the beginning of the session prior to 
CS 22 sending 74 data to MT 12. Further, the application context may be 
periodically updated, such as when changes occur t<j> sessions. Although 
discussed in combination with a video call scenario, the application 
context may include information about various types of applications and 
sessions and about multiple concurrent sessions and applications for MT 



[0026] As diagrammed in FIG. 6, after MT 12 transmits the application 
context to current access router 14, current access router 14 receives the 
application context and transmits 76 the application dontext to new access 
router 18. The timing of the transfer between access routers 14 and 18 may 
vary. For example, if MT 12 registers the application context at the 
beginning of the session, access router 14 may simply store the application 
context in memory 56 until it anticipates a handoff. It may anticipate a 
handoff based on the reception of a handoff trigger from MT 12, or based 
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on other information, such as by GPS tracking infojmation for MT 12. 
Conversely, if MT 12 registers the application context along with a 
handoff trigger, access router 18 may immediately transfer the associated 
application context for MT 12 and its current sessions p new access router 
18. Transfer 76 of the application context for MT 12 and its sessions from 
router 14 to router 18 may occur via Internet communications using IP 
messaging. 

[0027] Upon reception of the application context, new access router 18 
evaluates the application context to determine whethej* steps are necessary 
to introduce application-specific functionality for the session. It may do 
this by comparing the parameters contained in the application context with 
corresponding capabilities for transmissions via access network 20 and 
communication capabilities for domain 19. For example, in the video call 
scenario, access router 18 may evaluate the application context and 
determine that the bandwidth for communicating v|ith MT 12 in new 
administrative domain 19 is less than the established session, as originally 
supported by broadband WLAN administrative dopnain 15. As such, 
access router 18, in accordance with program instructions stored in 
memory 56, may establish a relationship with network entity 35 to provide 
necessary application-specific functionality for the session. In the case of 
the video call session, network entity 35 may be a transcoding proxy 
server 35 that transforms the high bandwidth video into low bandwidth 
video appropriate for transmission over the new wireless link. 

That is, Trossen at paragraphs 0024-0027, discloses an application context that may be 
formatted as an object that could be used by an object orientecjl application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain. Trosspn's application context that 
may be formatted as an object that could be used by an object oriented application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain, does not disclose receiving a 
domain state object, identifying an action in dependence upor^ the domain state object, or 

executing the action as claimed in the present application. A domain state object is 

I 

described at Applicant's original specification page 45, lines 10-20 as: 



The exemplary class diagram of Figure 3 includes aj domain state object 
(914). The exemplary domain state object of Figure 3 includes a userlD 
(405) identifying the user. The exemplary domain state object of Figure 3 
includes a user's metric vector (606). In many examples, the metric vector 
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is the user's current metric vector when the domain state object was 
created. The exemplary domain state object of Figure 3 includes a metric 
space (610). In many examples, the metric space (610) of the domain 
state object is the user's current metric space when the domain state object 
was created. The domain state object of Figure 3 also includes a current 
device state object "CDSO" (926). The current device state object (926) is 
a data structure including at least one device and the current value of an 
attribute of that device in the domain when the domain state object was 
created. 

Applicants further describe a domain state object at Applicants' original specification 
page 76, line 24 - page 77, line 5 as follows: 



In many examples of the method of Figure 13, a domain state object (914) 
is a data structure including information describing jhe state of the first 
domain and information describing the current condition of the user in the 
first domain (912). In various alternative embodiments of the method of 
Figure 13, the specific information contained in a domain state object will 
vary. Typical domain state objects however include information 
identifying devices within the first domain and the state or current value of 
an attribute of those devices. Typical domain state objects also include 
information describing a user's current condition within the first domain 
such as the user's current metric vector and the user's current metric 
space. 



As can be seen from these passages of Applicants' original sp deification, a domain state 
object is a data structure that includes information identifying devices, not a single 
device, within a first domain and a current device state object which is a data structure 
including at least one device, not only a single device, and the current value of an 
attribute of that device in the domain when the domain state object was created. 
Trossen's application context is created, however, for only a single device, the mobile 
terminal (MT 12), and does not include information identifying more than a single device 
within a first domain or a current device state object that includes at least one device as 
described in Applicant's original specification. Trossen's application context that may be 
formatted as an object that could be used by an object oriented application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain does not disclose therefore a 
domain state object as claimed in the present application. Because Trossen does not 
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disclose a domain state object as claimed in the present application it cannot be said that 
Trossen discloses receiving a domain state object, identifying 'an action in dependence 
upon the domain state object, or executing the action as claimed in the present 
application. Because Trossen does not disclose each and every element and limitation of 
Applicants' claims, Trossen does not anticipate Applicants' cjaims, and the rejections 
under 35 U.S.C. § 102(e) should be withdrawn. 



Relations Among Claims 



Independent claims 8 and 1 5 are system and computer program product claims for 
administering devices corresponding to independent method claim 1 that include "means 
for" and "means, recorded on [a] recording medium, for" administering devices. For the 
same reason that Trossen does not disclose a method for administering devices, Trossen 
also does not disclose systems and computer program producjs for administering devices 
corresponding to independent claims 8 and 15. Independent claims 8 and 15 are 
therefore patentable and should be allowed. 

i 

Claims 2-7, 9-14, and 16-21 depend respectively from independent claims 1, 8, and 15. 
Each dependent claim includes all of the limitations of the independent claim from which 
it depends. Because Trossen does not disclose each and every element of the 
independent claims, Trossen does not disclose each and every element of the dependent 
claims of the present application. As such, claims 2-7, 9-14, &nd 16-21 are also 
patentable and should be allowed. 

Conclusion 

Claims 1-21 stand rejected under 35 U.S.C. § 102 as being anticipated by Trossen. 
Trossen does not disclose each and every element of Applicants' claims. Trossen 
therefore does not anticipate Applicants' claims. Claims 1-21 are therefore patentable 
and should be allowed. Applicants respectfully request reconsideration of claims 1-21. 
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Claims 1-14 stand rejected under 35 U.S.C. § 101 on grounds 
is directed to nonstatutory subject matter. Claims 1-7, as currently 
physical structure for implementing the method recited in clailtns 
originally submitted, include physical structure for implementing 
claims 8-14. Applicants therefore respectfully request reconsideration 



Claims 5-7, 12-14, and 19-21 stand rejected under 35 U.S.C 
failing to particularly point out and distinctly claim the subject 
regard as the invention. The "second domain metric vector/ 
metric space:.." of claims 5-7, 12-14, and 19-21 need no extr^ 
Applicants therefore respectfully request reconsideration of c 
21. 



112, second paragraph, for 
matter which Applicants 
vector action list / user 

antecedent basis, 
tons 15-7, 12-14, and 19- 



The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 

Respectfully submitted, 
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